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TITLE: METHOD AND APPARATUS FOR A WEB BASED 
PUNCH CLOCK/TIME CLOCK 

SPECIFICATION 
BACKGROUND 

Cross Reference t:o Related Application 

This application is related to, incorporates by 
reference, and claims priority to the filing date of the 
following application filed by Finch, et al.: "TIME KEEPING 
AND EXPENSE TRACKING SYSTEM HAVING CUSTOMIZED GRAPHICAL USER 
INTERFACES", said application having been filed on January 
31, 2000 and having a serial number of 60/179,218. 
This application is related to and incorporates the following 
applications by Finch et al. being filed concurrently 
herewith : 

1. "METHOD AND APPARATUS FOR WIRELESS WEB TIME AND 
EXPENSE ENTRY VIA TIME KEEPING AND EXPENSE TRACKING SERVER 
ACCESS"; 

2. "METHOD AND APPARATUS FOR WIRELESS WEB TIME KEEPING 
AND EXPENSE ENTRY WITH A CALENDAR PROGRAM/ PERSONAL 
ORGANIZER"; 

3. "METHOD AND APPARATUS FOR PROVIDING FREQUENT FLYER 
MILES AND INCENTIVES FOR TIMELY INTERACTION WITH A TIME 
RECORDS SYSTEM"; 

4. "METHOD AND APPARATUS FOR PROVIDING PROMPT PAYMENT 
FOR TIME ENTRIES ENTERED BY WAY OF A TIME RECORDS SYSTEM"; 
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5. "METHOD AND APPARATUS FOR MONITORING CONTRACTOR 
PERFORMANCE"; 

6. "A TIME KEEPING AND EXPENSE TRACKING SERVER THAT 
GRANTS ACCESS TO RECORDS BASED UPON A USER'S ATOMIC 
ABILITIES"; 

7. "A TIME KEEPING AND EXPENSE TRACKING SERVER THAT 
INTERFACES WITH A USER BASED UPON USER'S ATOMIC ABILITIES"; 
AND 

8. "METHOD AND APPARATUS FOR UNIQUELY IDENTIFYING HARD 
COPY TIME SHEET FOR CROSS REFERENCE TO SYSTEM RECORDS". 

1 . Technical Field 

The present invention relates generally to computer 
based time keeping and expense tracking systems, and more 
particularly to such a system that may be customized on an 
entity, group, project, user or other basis and that is 
capable of communicating with a calendar application. 

2. Related Art 

The tracking of workers' time has been required since 
workers began working on an hourly basis. An early example 
of hourly time tracking was the punch clock system in which a 
time card was assigned to each worker. Upon commencing work, 
the worker had his or her card punched by a clock so that the 
work starting time could be recorded. Then, upon ceasing 
work, the worker had his or her card punched again so that 
the work ending time could be recorded. From these starting 
and stopping times, a record could be constructed for a 
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period, etc. This record was then used in preparing a 
paycheck for the worker and in creating other records 
relating to the time worked by a partial or complete work 
force . 

5 While the punch clock system worked admirably in a 

factory environment in which all workers worked in a single 
location, time keeping was more difficult where a workforce 
was distributed. For example, employment agencies specialize 
in placing workers in contract positions within different 

10 organizations that also have their own employees. A contract 
employee, while being paid by an employment agency, reports 
to an employee (usually a supervisor) within the company. 
The contract employee creates a time sheet based upon the 
work he or she performs and then passes the time sheet to his 

15 or her supervisor at the company for approval. When the 
supervisor approves the time sheet, the supervisor passes the 
time sheet to the employment agency. The employment agency 
then receives the time sheet and typically inputs the time 
sheet into a computer that produces a paycheck for the 

20 employee and bills the company for the employee's time. This 
process is slow, tedious, prone to errors and expensive. The 
cost of the overhead associated with this process may easily 
exceed twenty percent of the revenue that the employment 
agency receives for the employee . 

25 Another difficulty relating to time keeping relates to 

distributed work forces. Distributed work forces are now the 
norm, instead of the exception, not only for employment 
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agencies but for companies as well. In a distributed work 
force, employees/contractors may be distributed worldwide. 
Each employee/contractor is required to submit time sheets 
for each pay period. These time sheets are received at a 
central accounting office, the time entries contained 
thereupon are then input into a computer system, paychecks 
are produced, reports are produced, and invoices are produced 
when required. - While faxing or emailing time records to the 
central accounting office may expedite these operations, 
substantial effort must be expended in the process. 

Organization of time records is another difficulty faced 
in time keeping. While all employees may work for a single 
company, the employees may work for different divisions, in 
different departments, and for different supervisors within 
the same department. Time records must be segregated 

according to this organizational structure for accounting and 
budget tracking purposes. Further, in an employment agency 
scenario, the employment agency may service tens or hundreds 
of companies. While each of the contractors works for, and 
is paid by the employment agency, invoices must be submitted 
to the appropriate company. Further, within a particular 
company, a single contractor may work on more than one 
project, in more than one division, and for more than one 
supervisor. The contractor's time must be segregated 

accordingly when the invoice is submitted. To further 
complicate this effort, the contractor may be paid at 
different rates for this work, depending upon the project. 
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division, etc. These complexities further increase the 
difficulty in not only paying the employee but in generating 
an invoice for the company. 

Expense tracking includes its own difficulties, some of 
which are shared with time tracking. Expense reports must be 
prepared on a periodic basis for each member of a workforce, 
whether he or she is ' an employee or contractor. These 
expense reports must be received by an accounting department, 
allocated to the proper account, and reimbursement checks 
must be prepared. With a distributed workforce, at least 
those difficulties described above apply. Proper accounting 
of expenses and invoicing when required also introduces 
difficulties to the process. As may be seen, current systems 
do not readily facilitate time entry ' and monitoring for 
modern workforces that have employees that are continuously 
going from site to site. 

Thus, there is a need in the art for a timekeeping and 
expense tracking system that overcomes the shortcomings cited 
above as well as other shortcomings of the prior systems. 
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Summary of the Invention 

Thus, to overcome the shortcomings of the prior systems, 
among other shortcomings, a timekeeping and expense tracking 
("TKET") system constructed according to the present 
invention provides a plurality of users with the ability to 
access the system via the internet and via other wireline and 
wireless communication networks. The TKET system resides 
upon at least one server computer coupled to the internet and 
supports access from computer systems, web enabled 
telephones, personal data terminals, and other enabled 
devices including wireless personal digital assistants 
(PDAs) . The TKET system may therefore be accessed from both 
wired and wireless devices. In one embodiment, users employ 
browser software to access the TKET system and require no 
specialized client software. 

In order to support the many and varied needs of 
companies using the TKET system, the TKET system supports 
configurable graphical user interface screens ("GUI 
screens") . GUI screens are those displays provided to users 
of the TKET system when the users access the TKET system. Via 
the GUI screens, the users input their time and expense 
records. The GUI screens are configurable to alter the 
objects presented, the layout of the objects and information 
presented, the color schemes presented, the timekeeping or 
expense tracking information required from the user, and in 
other ways that cause the TKET system to be more effective. 
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GUI screens may be customized on a company-by-company 
basis, a department-by-department basis, a group-by-group 
basis, a project-by-project basis, and a user-by-user basis 
or upon another basis. A single TKET system may be used to 
service the time keeping and expense tracking needs of a 
plurality of companies, each of which has a plurality of 
divisions, a plurality of departments, a plurality of groups 
and a plurality of employees/contractors. Thus, the 

configurability of the TKET system allows differing GUI 
screen presentations to be created and presented such that 
each group of users is employing a different system. 

GUI screen preferences for sets of users of the TKET 
system may be organized in a hierarchical basis to simplify 
the GUI screen creation and presentation operations. In a 
GUI screen preference hierarchy, a top level of the hierarchy 
possesses a respective set of GUI screen preferences that are 
sufficient to create a user's GUI screen. Each lower level 
on the hierarchy also possesses a respective set of GUI 
screen preferences. Each user serviced by the TKET system 
resides at a particular location on the hierarchy. With this 
hierarchy position determined, a GUI screen may be created 
for the user. In creating the GUI screen, the user's 
location in the hierarchy determines his ability level for 
making changes because he inherits the GUI screen preferences 
of all other higher level users in the hierarchy. However, 
GUI screen preferences of successively lower levels of the 
hierarchy displace conflicting GUI screen preferences of 

8 
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higher levels of the hierarchy. Thus, a GUI screen for a 
particular user of the TKET system will have his or her GUI 
screen preferences determined along a top to bottom hierarchy 
path . 

5 The TKET system also generates GUI screens depending 

upon the type of terminal from which a user accesses the TKET 
system and the connection over which the user accesses the 
TKET system. A GUI screen created for the user when the user 
accesses the TKET system from a palm-top computer is simpler 

10 than a GUI screen created for the user when the user accesses 
the TKET system from a desktop computer. Further, when the 
user accesses the TKET system from a wireless device, the 
bandwidth of the available data path from the TKET system to 
the user's terminal will also be considered. A less complex 

15 GUI screen will be created and provided to the user when 
lesser bandwidth is available over which to transmit the GUI 
screen to the user. This operating feature is particularly 
important when the user accesses the TKET system from a 
wireless device. 

20 The invention further includes interfacing the TKET 

server with a calendar application that is hosted on a user 
terminal that comprises either a desktop computer, a laptop 
computer or a PDA. In one embodiment of the invention, the 
TKET server communicates directly with the calendar 

25 application if the TKET server knows the communication 
protocol for the specific calendar type. In another 

embodiment of the invention, an application is installed into 
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the user terminal that serves as an interface between the 
TKET and the calendar application. 

Other aspects of the present invention will become 
5 apparent with further reference to the drawings and 
specification, which follow. 
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Brief Description of the Drawings 

A better understanding of the present invention can be 
obtained when the following detailed description of the 
preferred embodiment is considered in conjunction with the 
following drawings, in which: 
5 FIGURE 1 is a system diagram illustrating a multimedia 

electronic mail system constructed and operating according to 
the present invention. 

FIGURE 2 is a functional block diagram illustrating a 
TKET server coupled to a user terminal according to the 
10 present invention, 

FIGURE 3 is a functional block diagram that illustrates 
an expanded TKET server system coupled to a user terminal 
according to one aspect of the present invention. 

FIGURE 4 is a software system configuration chart that 
15 illustrates to various software layers according to an 
embodiment of the invention. 

FIGURE 5 is a functional block diagram illustrating the 
relationship between users with respect to a TKET server 
formed according to the present invention. 
20 FIGURE 6 is a chart that illustrates the hierarchical 

relationship between different users wherein the hierarchical 
relationships defined levels of ability to define the 
characteristics and arrangement of a GUI screen page 
according to a preferred embodiment of the invention. 

25 



11 



Docket No. JOUR-004 



FIGURE 7 is an exemplary display of a GUI screen 
according to one embodiment of the invention. 

FIGURE 8 is an illustration of a series of GUI screen 
screens that collectively illustrate a concept of users 
having differing and relative levels of atomic abilities for 
modifying the contents and arrangement of GUI screen screens 
according to one embodiment of the invention. 

FIGURE 9 is a flow chart that illustrates a method 
performed by a TKET server for setting GUI screen preferences 
for a user. 

FIGURE 10 is a flow chart illustrating a method for 
generating a GUI screen page to a user and for receiving data 
inputs from the user for storing and processing. 

FIGURE 11 is a functional block diagram illustrating a 
TKET server in communication with a user terminal according 
to an alternative embodiment of the invention. 

FIGURE 12 is a table illustrating a method within a TKET 
server for generating a GUI screen display at a remote 
terminal according to a preferred embodiment of the 
invention . 

FIGURE 13 is a table determining whether to generate a 
set of signals for displaying either, a full, reduced or 
minimal GUI screen display based upon communication path 
characteristics according to one aspect of the present 
invention . 

FIGURE 14 is a flow chart that illustrates a method 
according to the present invention. 
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FIGURE 15 is a flow chart illustrating an inventive 
method for receiving time tracking signals from a 
telecommunication switch according to a preferred embodiment 
of the invention , 

FIGURE 16 is^ a functional block diagram illustrating the 
circuitry within a time keeping and expense entry server 
according to one embodiment of the present invention. 
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Detaii^ed Description of the Drawings 

FIGURE 1 is a system diagram illustrating a time keeping 
and expense tracking (TKET) system 100 constructed and 
operating according to the present invention. A TKET server 
102 couples to the internet 104 (World Wide Web) and 
converses with all other devices using one or more packet 
switched protocols supported by the internet 104. A 
telephone network 106 (which may be the public switched 
telephone network ("PSTN'') or another telephone network 
couples to the internet 104 via a gateway 108. Further, a 
wireless network 110 couples to the internet 104 via a 
gateway 112. The manner in which the internet 104 (or other 
packet switched networks) couples to the telephone network 
106 and to the wireless network 110 is generally known. 
Thus, the interaction between the internet 104 and the other 
networks 106 and 110 will be described only as it relates to 
the present invention. And, of course, the structure 

illustrated in FIGURE 1 is an example structure. Other 
structures may be constructed and operate according to the 
present invention to support time keeping and expense 
tracking operations . 

Computers 114 and 116 couple to the internet 104 and may 
interact with the TKET server 102 through this connection. 
While computer 114 has a direct connection to the internet 
104, computer 116 must access the internet via an internet 
Service Provider (ISP) 118. Many users currently access the 
internet via an ISP, as illustrated with the connection for 
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computer 116. However, some computers currently access the 
internet via an Intranet or other coupling network. In this 
construction, an ISP may not be required. Further direct 
connections to the internet are already possible such as 
shown with computer 114. Thus, simply stated, the structure 
illustrated in FIGURE 1 provides a platform of operation for 
the present invention but must not be constructed to limit 
the teachings of the present invention. 

Web-enabled telephones 124 and 126 couple to the 
telephone network 106. These telephones 124 and 126 each 
have displays upon which a GUI screen may be presented to the 
user. The telephone network 124, as was previously described, 
may be the PSTN, which transmits data in a PCM format. In 
another embodiment, the telephone network 124 may be a packet 
switched network that supports packet-based communications. 
The teachings of the present invention, therefore, apply 
equally well to current or future telephone network 
technology . 

Wireless devices 120, 121 and 122 wirelessly connect to 
the wireless network 110. The wireless network 110 may be 
cellular based, satellite based or otherwise structured to 
provide wireless communication service within a service area. 
Wireless device 122 is a portable computer that services 
communications over a wireless link to the wireless network 
110. Wireless devices 120 and 121 are personal data 

assistants that wirelessly communicate with the wireless 



Docket No. JOUR-004 



network 110. The wireless network 110 communicates with the 
internet 104 via the gateway 112. 

A local area network/wide area network (LAN/WAN) 128 
couples to the internet 104 via a firewall 130. At least one 
5 computer terminal, e.g., computer 132, couples to the LAN/WAN 
and may communicate with the TKET server 102 via the LAN/WAN 
128 and the internet 128. The LAN/WAN may be supported by a 
company, a service provider or another organization. 

The TKET server 102 may be operated by a single company 
10 or a plurality of companies that use the TKET server 102 to 
support its timekeeping/expenses. Alternately, the TKET 
server 102 may be operated by an application service provider 
(ASP) that sells timekeeping and expense services to a 
plurality of customers. The timekeeping services provided by 
15 the ASP may be bundled with other services so that the ASP 
provides a suite of services to its customers. 

According to the present invention, a plurality of users 
accesses the TKET server 102 via differing communication 
paths and using differing terminal devices. Time and expense 
20 information is uploaded from the terminal devices to the TKET 
server 102 where it is stored and later used to generate 
invoices, paychecks, reports, and other alternate records. 
Because the TKET server 102 is accessible from any location 
having internet 104 access, the TKET server 102 provides 
25 ubiquitous service worldwide. Thus, the TKET server 102 as 
easily services distributed workforces as it does centralized 
work forces. For example users at terminal devices 120, 132 
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125 and 116 may work for a single employer/contractor at 
differing physical locations. However, in reporting time and 
expense information, they simply access the TKET server 102 
via respective network connections. 

A single user may use multiple and differing terminal 
devices to access the TKET server 102. Because of this, the 
user is not precluded from entering his or her time from a 
single terminal device. While the user is traveling, he or 
she may use a portable computer 122 or personal data 
assistant 121 to enter time. However, while working or at 
home, the user may use his or her personal computer 114 to 
enter time and expense information. Thus, as compared to 
prior timekeeping/expense systems, the TKET server 102 
provides a centralized service environment that is not 
limited by the users' equipment. 

The design of the present invention is particularly 
advantageous in that it allows an employer to monitor time 
keeping and expense tracking in a real-time manner. Stated 
differently, by requiring an employee to access the system to 
enter his start and stop ties, the system serves as a time 
clock. Moreover, the system includes the flexibility of 
allowing an employee (user) to enter previously worked by un- 
entered time. For example, an employee may need to enter 
travel time . 

With respect to the time clock feature of the invention, 
a GUI screen for a user of a wireless PDA terminal 121, for 
example, may have separate objects for start and stop times. 
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Thus, the PDA may be programmed to establish a connection 
with the TKET server and to automatically upload a start or 
stop time when so requested by the user. With the present 
system, a PDA may serve as a portable time clock for the user 
to help him track his time. 

Continuing to refer to FIGURE 1, TKET server 102 
generates communication signals 134 that are to be delivered 
to any one of the plurality of terminals shown in FIGURE 1. 
The communication signals 134 are created in a form to 
trigger terminal user software to generate displays 
containing information defined within communication signals 
134. For example, communication signals 134 may include 
signals in a form that trigger and that can be used by a 
plurality from terminal software to create a GUI screen. The 
form of the communication signals 134 and the content therein 
directly affect the display at the receiving terminal. For 
example, communication signals 134 actually comprise a large 
number of signals or information that result in a specified 
GUI screen being displayed on the terminal display. Thus, 
either for a terminal having a limited capacity for receiving 
and handling large amounts of information or for a network 
path having low bandwidth data throughput capacity, the 
magnitude or total amount of signals that comprise 
communication signals 134 will be reduced thereby resulting 
in the display of a reduced GUI screen page. In the case, by 
way of example, of a mobile terminal, the signals within 
communication signals 134 may be so limited that little more 

18 
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than text is transmitted to the terminal. 

The communication signals 134 also include control 
information to prompt the receiving terminal to generate a 
response indicating a user selection of options or questions 
asked within the GUI screen for the response signals 136 are 
received by TKET server 102. 

For most user terminals, the response signals 136 use 
the hypertext transfer protocol (HTTP) that is used by web 
servers and client browsers to communicate over the World 
Wide Web. Generally, the protocol is used for moving 
documents around the internet. Additionally, terminals 

usually employ hypertext mark-up language (HTML) for creating 
World Wide Web pages. Accordingly, the TKET server 102 can 
estimate the capabilities of the terminal, and perhaps the 
transmission data path from the HTTP and HTML information 
that is received as a part of response signals 136. As will 
be explained in greater detail herein this application, TKET 
server 102 determines the characteristics of the GUI screen 
display that are to be created at the user terminal according 
to the content of response signals 136. In addition to the 
HTTP and HTML information from which TKET server 102 may 
infer terminal or communication path capabilities, an actual 
synchronized address selection by the user to which response 
signals 136 are being routed may be used, in an alternate 
embodiment, by the TKET server 102 in determining GUI screen 
display characteristics. Alternatively, response signals 136 
may merely include an indication of a user selection from 
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which a corresponding GUI screen display is generated. 

Other factors are also used by TKET server 102 to 
determine what GUI screen display signal characteristics are 
appropriate. By way of example, the TKET server 102 is 
operable to determine the number of gateways in the 
transmission path between it and the user terminal from 
examining the http information associated with a received 
signal. For example, the network of Figure 1, a Gateway 108 
is shown to exist in the path between TKET server 102 and 
telephones 124 and 126 of telephone network 106. Between 
TKET server 102 and user terminal 122, there not only exists 
a Gateway 112, but also a wireless network 110 that 
introduces substantial propagation delays. Accordingly, by 
determining how many Gateways exist in the path and other 
characteristics of the path such as whether the communication 
signals are being routed through a telephone network 105, a 
local area or wide are network 128, or a wireless network 
110, as well as the number of Gateways through which 
communication link passes, TKET server 102 is able to 
determine an approximate value for through put capacity. For 
example, merely having to go through a wireless network 110 
might, in the described embodiment, result in TKET server 102 
transmitting, at most, a reduced set of display signals for 
forming a reduced GUI screen display. 

FIGURE 2 is a functional block diagram illustrating a 
TKET server coupled to a user terminal according to the 
present invention. . A user terminal 204 communicates with 
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TKET server 208 by way of interface 212. Interface 212 may 
comprise any combination of an ISP, a gateway and an 
internet, a wireless network, a PSTN or any other 
communication network. TKET server 208 also is coupled to 
database 216 that is for storing user information including 
user selected GUI screen display parameters. 

TKET server 208 comprises a session interface module 
220, a GUI screen definition module 224 and a GUI screen 
display module 228. Each of these modules operates in 
concert to support the disclosed invention herein. To 
illustrate, GUI screen definition module 224 is for storing 
default GUI screen page parameters and GUI screen display 
definition information for creating GUI screen pages on a 
user terminal display. Additionally, module 224 includes 
information for defining logic for rearranging, renaming, 
adding, and deleting time entry or expense tracking 
components. The specific logic contained therein is better 
explained in the discussion of the figures that detail 
operation of the invention. 

The inventive system is operable to enable a user to 
customize the GUI screen displays to a degree not seen in 
other display systems, and more particularly, in time and 
expense tracking systems. To enable the user to select 
display parameters, the inventive system includes a GUI 
screen display module 208 that creates GUI screen displays 
according to the definition information stored in GUI screen 
definition module 224. Additionally, GUI screen display 
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module includes logic for creating displays according to the 
display parameters selected by the user that are stored 
within database 216. 

Database 216 is for storing customized display 
parameters selected by a user. For example, the number, 
arrangement and names of elements within the rows and columns 
of a GUI screen display page on a per user basis are stored 
within database 216. In the preferred embodiment of the 
invention, database 216 is for storing multiple display pages 
for each user that requires multiple pages. 

By way of example, a user may want to define multiple 
GUI screen pages for display on his terminal screen according 
to the terminal type. If the user, for example, typically 
accesses his time and expense tracking system either with a 
PDA or with a desktop computer terminal, his display 
capabilities will vary according to the capacity of the 
terminal in terms of bandwidth, memory, and display 
processing throughput capacity. Accordingly, database 216 is 
formed to include software instructions and memory capacity 
to store multiple GUI screen display pages according to user 
need and GUI screen display module 208 is formed to include 
logic for selecting between the multiple GUI screen pages. 

In addition to database 216 that stores multiple display 
pages for each user, session interface module 220 is for 
determining the terminal type through which the user is 
accessing the TKET server 208. More specifically, session 
interface module 220 includes software instructions that 
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define logic for determining the bandwidth and terminal type 
of the user terminal. The session interface module 220, in 
one embodiment, produces a GUI screen selector signal for the 
GUI screen display module 228 to determine what GUI screen 
5 display is to be created for the user terminal 204 the GUI 
screen selector signal. 

There are many different ways in which the session 
interface module 220 may determine the user terminal type. 
In one embodiment of the invention, the user specifies his 

10 terminal type by selecting a corresponding URL when accessing 
the TKET server 208. By way of example, the user is 
instructed to use a first URL for accessing the TKET 208 when 
the system is being accessed with a PDA and a second URL when 
the system is being accessed with a desktop or laptop 

15 computer. 

In another embodiment of the invention, a terminal ID is 
transmitted to the TKET server 208 that identifies the 
terminal type. For this embodiment, session interface module 
examines the contents of a database, e.g., database 216, to 

20 determine the terminal type based upon the terminal ID. In 
yet another embodiment of the invention, the user is given an 
option to select from one of several GUI screen display 
modes. For example, the user may be given the option to 
select either a FULL or REDUCED GUI screen display wherein 

25 the display modes relate to the capacity of the user display 
terminal . 
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As another aspect of the invention, the session 
interface ID module examines the signal path through which 
the GUI screen page is to be delivered to the user terminal. 
For example, if the signal path includes a wireless branch, 
5 it may determine to transmit a GUI screen page that would 
have a smaller memory or data transport capacity requirement. 

In yet another embodiment of the present invention, the 
session interface module transmits a signal to the user 
terminal to measure a response time. The GUI screen display 
10 module then selects GUI screen display page types according 
to the response time. For this embodiment, it is assumed 
that a response time corresponds to a network data transport 
capacity. Accordingly, a GUI screen page requiring the 
transmission of lesser amounts of data is selected for those 
15 network paths whose transport speed is lower. 

In operation, a user connects to TKET server 208 with 
his terminal 204 to enter or review time and/or expense 
information. Session interface module 220 determines the 
user terminal type, if necessary, by sending a message to the 
20 user to prompt the user to select a GUI screen display page 
type or mode. The GUI screen display module then builds and 
transmits a GUI screen display page based upon the GUI screen 
selector signal value created by the session interface module 
220 and based upon the user specific GUI screen page 
25 information stored within database 216. 

The above described embodiment includes having multiple 
GUI screen pages for each user, if necessary. In an 

24 
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alternate embodiment, each user defines only one GUI screen 
page. The parameters of the page include graphical 

information including unique fonts, color patterns, graphical 
symbols and related spacing and layout of all of these GUI 
screen page elements and aspects. If, however, the GUI 
screen selector signal indicates that the user terminal has a 
reduced data capacity in terms of processing speed or memory, 
the GUI screen display module builds a GUI screen display 
page that omits certain elements of the page. For example, 
if the user terminal type is a PDA having only "black and 
white" color capability, the GUI screen display module would 
build a GUI screen page without color information. 
Additionally, the GUI screen display module may build a GUI 
screen page that omits certain graphical signals. Thus, for 
this embodiment, the GUI screen page is said to be ''implied'' 
from the stored GUI screen page. 

In yet another alternate embodiment of the invention, 
the GUI screen display module builds an implied page based 
upon one of several different user created GUI screen pages 
stored within database 216. For example, if the GUI screen 
selector signal indicates that the smaller (in memory size) 
of the two GUI screen pages is to be built for transmission 
to the user terminal, the GUI screen display module may still 
build a GUI screen page whose elements are implied from the 
selected GUI screen page. To illustrate, the user may have 
selected a smaller GUI screen page, but based upon the user 
terminal type, the amount of information of the smaller GUI 
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screen page may still exceed the capacity of the user 
terminal. Thus, an even more limited GUI screen must be 
created or "implied" from the selected screen. For example, 
if the user terminal is a cellular device having limited 
5 display and data processing capability, the GUI screen page 
may be reduced to being little more that a string of 
alphanumeric characters even through the selected server was 
a "REDUCED" GUI screen. 

FIGURE 3 is a functional block diagram that illustrates 

10 an expanded TKET server system coupled to a user terminal 
according to one aspect of the present invention. The system 
of FIGURE 3 is similar to that shown in FIGURE 2 except that 
the TKET server of FIGURE 2 is replaced by a network of TKET 
servers. Primarily, the network of TKET servers shown 

15 generally at 300 illustrate that the components (individual 
TKET servers) of the TKET server network are coupled to 
communicate with each other to produce a scaleable TKET 
server network that can be formed to satisfy system 
requirements. As may also be seen, the TKET server network 

20 comprises application servers that are coupled to the users 
through a plurality of web servers. 

FIGURE 4 is a software system configuration chart that 
illustrates to various software layers according to an 
embodiment of the invention. More specifically, the chart of 

25 FIGURE 4 illustrates relative arrangement and Each layer 
represents different levels of abstraction with respect to 
the software and its functionality in a TKET server. 

26 
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The lowest level layer is the database interface layer 
410. Database interface layer 410, as its name implied, is 
the layer at which computer instructions cause a TKET SERVER 
processor to interact with a database within a storage device 
to obtain specific user selected GUI screen display 
parameters as well as stored user data. The second layer is 
the coarse object layer 420. The course object layer 420 is 
the layer at which the programmer can access a whole table of 
objects as one object. 

The third layer is the fine object layer 430. The fine 
object layer is the layer at which single objects represent 
one user, one project, or one such other object in the 
system. The fourth layer is the presentation layer 440. A 
presentation layer is a layer at which HTML, WAP or HDML is 
prepared for the user and user input is passed back to the 
program. For example, the computer instructions at the 
presentation layer are those instructions that prompt a 
processor to generate the appropriate type of GUI screen. 
The fifth layer is the common gate interface (CGI) script 
layer 450. CGI layer 450 is the layer at which presentation 
data is passed up to the web server. 

FIGURE 5 is a functional block diagram illustrating the 
relationship between users with respect to a TKET server 
formed according to the present invention. TKET SERVER 504, 
an application server, is coupled to communicate with a 
plurality of users by way of a communication network. A user 
TKET server 504 is coupled to communicate with a user 
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terminal 508 and to transmit GUI screen displays thereto. 
Additionally, user terminals 512 and 516 are coupled to 
communicate with TKET server 504. 

Dashed lines 520 and 524 are shown between user terminal 
508 and user terminals 512 and 516 to illustrate a business 
relationship between the users of the respective user 
terminals. By way of example, if the user of user terminal 
508 desires to establish a time management and tracking 
service and to establish a service relationship with the 
Operator of TKET server 504, then the user of user terminal 
504 is, for the purpose of this example, the administrator 
for the time management and tracking company. Thus, the 
users of terminals 512 and 516 are the clients of the user of 
terminal 504. 

In the illustration of FIGURE 5, there also exists a 
business relationship between the users of terminals 512 and 
516. For simplicity, an illustration of the business 

relationship between user terminals 528 and 532 and user 
terminal 516 is shown. User terminal 512, has business 
relationships with other lower ability users that are not 
shown herein. 

One reason that the business relationships are indicated 
in FIGURE 5 is to illustrate why each layer of users has 
different ability levels. Thus, for example, user 508 may be 
an director for the time keeping and expense tracking 
function subscribed or used by each of the lower ability 
level users 512, 516, 528 and 532 and supported by the 
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operator of TKET server 504. Similarly, users 512 and 516 
may be managers for the time keeping and expense tracking 
function. Users 528 and 532 may be mere users. 

Alternatively, they too may be managers having yet lower 
5 ability level users. For example, if each of the users 528 
and 532 represent a company, each company may have 
organizational units such as section, departments, or 
divisions that are lower ability level users. A better 
understanding of the abilities of the different level users 

10 is explained in the discussion relating to FIGURE 8. 

FIGURE 6 is a chart that illustrates the hierarchical 
relationship between different users wherein the hierarchical 
relationships defined levels of ability to define the 
characteristics and arrangement of a GUI screen page 

15 according to a preferred embodiment of the invention. The 
chart of FIGURE 6 illustrates the relationship of three 
hierarchical ability levels of users. The first hierarchical 
level shown generally at 604 represents an application 
service provider (ASP) that also serves as an administrator 

20 for the example shown herein. The administrator originally 
receives a GUI screen page that is set up according to a 
plurality of default settings. Being administrator, however, 
the objects of the GUI screen page may readily be modified by 
the ASP/Administrator . 

25 The second hierarchical level shown generally at 608 

includes five users 612, 616, 620, 624 and 628, each of which 
may have ' additional lower level users as , shown at 
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hierarchical level 632. For example, user 628 further 
includes four lower ability level users 636, 640, 644 and 
648. While not shown specifically herein FIGURE 6, each of 
the users of level 632 may also have additional lower levels 
users. For example, if each user of level 632 represents a 
different company, there may still exists several lower 
layers according to the size of the company and the number 
and arrangements of the divisions of the company. 

Continuing to refer to FIGURE 6, each level of user 
receives a GUI screen page having a default arrangement and 
object labels and contents. According to the selections of 
all of the users above the present -user in terms of what may 
or may not be modified, the present user may modify the 
arrangement and label values and well as content of the rows, 
columns and objects of the GUI screen page. A better 
explanation of the relative abilities of users is explained 
in the discussion of FIGURE 8 below. 

In general, however, each user receives a GUI screen 
page having a default set of values that is determined by the 
higher level of users. Thus, the ASP/Administrator of group 
604 has a first set of default values. The users of group 
608 receive GUI screen pages whose default settings are 
determined by the ASP/Administrator 604. Similarly, the 
lower level users of group 632 receive GUI screen pages whose 
default values are determined by the ASP/Administrator and by 
the higher level user of group 608 to which the user of group 
632 belongs. For example, user 628 and ASP/Administrator 604 
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determine the default settings of users 636, 640, 644 and 
648. In general, each hierarchical level of FIGURE 6 has a 
different set of GUI screen default settings according to the 
relative placement of the user. 

While the table of FIGURE 6 illustrates only three 
levels of users, it is understood that there may be 
additional levels below the third level shown generally at 
632. While there may not be any higher levels than shown in 
FIGURE 6, it generally is possible to have additional levels 
in either direction if the highest level shown is not the ASP 
as is the case in FIGURE 6. 

The hierarchical relationship between the users affects 
more than screen definitions. More specifically, access 
control lists may be defined that specify access to specified 
information or lists of information. Generally, each user 
may transparently view the GUI screen screens of all lower 
level users. If a user belongs to multiple groups, for 
example, wherein there is a plurality of lower level users 
within each group, the user will have the ability to 
transparently review or even to modify the content of the GUI 
screen screens of the lower level users in each group. Each 
of the lower level users, however, can only review the GUI 
screen pages of their lower level users. They may not review 
the GUI screen pages of users at the same or at higher 
hierarchical levels. In such a case, the user is ''hidden'' 
from those users whose screens he cannot access. 
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Moreover, because project codes are similar to expense 
accounts, it is often desirable to allow the project codes to 
be viewed by lower level users in a selective manner. Thus^ 
a user, e.g., a manager level user, may select what codes may 
be viewed by the users in a given group through the access 
control lists. If a lower level user also acts as a manager 
for his lower level users, the upper level manager will have 
access to view the codes and access control lists defined and 
controlled by the lower level manager. 

The function of hiding project codes may also be 
performed on a per user basis through the use of the access 
control lists. Thus, a manager may specify in an access 
control list those lower level users that have access to a 
given code. 

FIGURE 7 is an exemplary display of a GUI screen 
according to one embodiment of the invention. The screen of 
FIGURE 7 includes five groups of information 702, 704, 708, 
712 and 715. As has been discussed above, different users 
have different ability levels in terms of the extent to which 
they may make selections for the characteristics of a GUI 
screen. The example of FIGURE 7 illustrates a screen that is 
observed by a user not having the highest ability level. 
Thus, the screen received by the user of the screen of FIGURE 
7 includes groups 702, 704 and 708 whose objects are not 
modifiable. By way of example, group 702 includes an object 
reserved for displaying a corporate logo while group 704 
includes an object of displaying a corporate name. Group 708 
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includes at least one object that includes departmental 
identifiers. Similarly, group 716 includes an object for 
displaying a banner or advertisement that may not be modified 
by the user of the screen illustrated in FIGURE 7. 

The objects of group 712, however, are modifiable by the 
user of the screen shown in FIGURE 7 . For the example 
herein, the objects of group 712 are for storing the actual 
time or expense entries. Moreover, the actual arrangement of 
the columns and rows of group 712 are modifiable. Thus, 
based upon user selection, rows may be displayed as columns 
or vice versa. Additionally, the actual names given to these 
rows or columns are modifiable. In the preferred embodiment 
of the invention, the screen is initially received by the 
user with a set of default names and values. Then, for each 
row or column, the user may activate a pull down menu to 
select from one of a group of alternate names. In an 
alternative embodiment of the invention, the user may also 
type in a name if one of the alternative names does satisfy 
the user's requirements. For example, a row labeled as 
''entertainment" may have alternate names including 'Mining", 
"alcohol", or "sporting events". In the alternate embodiment 
of the invention, the user may choose to type a label that 
does not exist such as "Golfing Fees" if, for example, the 
user entertains clients on the golf courses. 

The TKET server 700 supports fully customizable GUI 
screens, which are the presentation, made to the user when 
requesting time entries and/or expense information. Each 
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time entry typically includes at least five components: (1) 
an identity, e.g., the user's identity; (2) a corresponding 
date or date range for the time entry; (3) the duration of 
time for the time entry, or alternately starting and stopping 
times for the time entry; (4) elements of the time entry, 
e.g., project code, project sub-code (s), time categories and 
subcategories, etc., and (5) comments regarding the time 
entry. In the described embodiment, even the name, size and 
arrangement of the comments field (object) is configurable by 
the user. As may be seen from examining group 712 in FIGURE 
7, the top row of object titles represent the default 
settings that are provided by a higher level user while the 
dashed objects below the top row of object titles represent, 
more generally, that a pull down menu may used to allow the 
user to select from a list of object names for each object. 

The chart of FIGURE 7 illustrates, therefore, a time 
entry GUI screen session for an employee having the lowest 
ability level/role for defining the screen display 
parameters. The objects of group 712 may be arranged by the 
user in any order or may even be renamed by the user. 

FIGURE 8 is an illustration of a series of GUI screen 
screens that collectively illustrate a concept of users 
having differing and relative levels of atomic abilities for 
modifying the contents and arrangement of GUI screen screens 
according to one embodiment of the invention. Referring now 
to FIGURE 8, each of the three GUI screen screens contains 
five rows and one column of objects. In the first GUI screen 
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810, it may be seen that all five objects 811 through 815 are 
highlighted (as indicated by the box around the object) to 
indicate that each of the objects may be modified. The GUI 
screen of FIGURE 8 is one that is under the control of a TKET 
5 server administrator having the highest level of ability to 
modify the objects within the screen. Accordingly, all five 
objects are modifiable by the user (administrator) . An 
access list stored within the TKET server defines the access 
level of the user. From the stored access information, the 

10 TKET server determines that all five rows are modifiable by 
the user to whom the screen 810 is to be transmitted. 
Accordingly, each of the five objects is sent in a format to 
enable the receiving user to make modifications. 

The screen shown at 820 shows the same five objects 511 

15 through 815 of screen 810 but that only objects 812 through 
815 are highlighted. That object 811 is not highlighted 
indicates that the user of screen 820 has a lower ability 
level and, more specifically, cannot modify the display the 
content of object 811. In general, if object 811 represents 

20 a value or symbol that the administrator does not want its 
lower level users to modify, then the contents of that object 
appear for all of the lower ability level users. 

The screen shown at 830 also includes the same five 
objects but only objects 813 through 815 are highlighted 

25 illustrating that the user of screen 830 may not modify 
objects 811 and 812. While object 811 was made un-modif iable 
for both of the lower ability users of screens 820 and 830,- 
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the user of screen 820 made object 812 un-modif iable for the 
user of screen 830. While not explicitly shown in FIGURE 8, 
it should be understood that there inight well be additional 
screens that represent additional lower ability users. For 
example, the user of screen 830 may represent a company. In 
such a case, each of the lower ability screens would relate 
to organizational units of the company. No particular limit 
as to the number of ability levels is intended by the 
illustration of FIGURE 8, which includes only three ability 
levels. 

Continuing to refer to FIGURE 8, it may be seen that a 
reporter 840 is coupled to receive each of the GUI screen 
screens 810, 820 and 830 from the user terminals displaying 
them. A reporter may be any type of device that is for 
storing or displaying information of the type being supported 
on each of the GUI screen screens. By way of example, if the 
system of FIGURE 8 relates to time entry, the reporter may be 
a terminal and screen of a supervisor that is monitoring the 
time entries of each of the users of the three GUI screen 
screens 810, 820 and 830. Alternatively, the reporter may be 
a report generating routine stored within TKET server 102 (of 
FIGURE 1, for example) and executed by a processor within 
TKET server 102. 

While the example of FIGURE 8 includes an illustration 
of how objects may be changed, it is to be understood that a 
user also may be allowed by a higher ability level user 
(e.g., a manager or an administrator) to change other 
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features of the GUI screen including color, font type, etc. 
Moreover, as mentioned before with respect to FIGURE 7, even 
the lowest ability level user has the capacity to rename 
objects. Thus, for a reporter 840 to be able to meaningfully 
5 monitor the time keeping and expense tracking of the user, a 
database or table is needed to map the changes made by the 
user from the default settings provided to him. 

The database or table thus enables the reporter to 
analyze numbers and add values from different users having 

10 different names but representing the same basic parameter. 
For example, one user may track a term named "Hourly value" 
while another user tracks a term name ''Client cost" wherein 
both numbers represent the amount that the client or project 
is to be charged for the contract employees time and effort, 

15 Thus, if the mapping of object names is found within database 
216 of FIGURE 2, for example, reporter 840 must communicate 
with database 216 to properly generate the time and expense 
tracking reports. 

FIGURE 9 is a flow chart that illustrates a method 

20 performed by a TKET server for setting GUI screen preferences 
for a user. First, the TKET server receives and establishes 
a connection with a user and determines the user ID (step 
904) . As was shown in FIGURE 1, the connection may comprise 
a path through any one of the public switched telephone 

25 networks, through a wireless network, through a local area 
network, through any one of the various internets or through 
any combination of these networks. 
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After the connections is established, the TKET server 
determines the user's role and associated abilities for 
defining and modifying objects of a GUI screen (step 908). 
For example, if the user role is that of an administrator, 
the TKET may allow the user to make any change from an 
original default screen that is desired (unless, of course, 
the TKET server operator chooses to make one or more objects 
fixed (e.g., a small logo inconspicuously displayed). 
Alternatively if the user is a lower ability level user 
relative to the administrator, then the TKET server must 
determine the ob j ects that the user is allowed to modify or 
change . 

Once the TKET server determines the user role and 
corresponding abilities, it provides the options to the user 
for making changes to the GUI screen page (step 912). As 
indicated before, these options are options for modifying GUI 
screen display parameters of a default page. In an alternate 
embodiment , however, a default page is not provided for the 
highest ability level user. For this embodiment, the highest 
level user (administrator) must define the layout of the GUI 
screen page. The default page of course is the page settings 
created by a user that is one ability level higher than the 
present user and includes the selections of all users that 
are at a higher ability level than the present user. In the 
case of the highest ability level user (e.g., an 
administrator) , the GUI screen default page is created by the 
operator of the TKET server for the purpose of providing the 
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administrator a starting point for creating and defining his 
GUI screen page. 

Thereafter, the TKET server receives the user's GUI 
screen page definitions (step 916) . The definitions can be 
5 in the form of fixed data values, text (e.g., formulas for 
making calculations that are to be displayed) , and row and 
column names, row and column arrangements. 

After each GUI screen definition is received, the 
invention includes accepting and modifying the GUI screen 

10 definitions from the default value (s) (step 920). This step 
includes storing the received GUI screen definitions with 
respect to the user ID. After each GUI screen definition is 
received, the invention includes determining whether the user 
is through making changes and defining his GUI screen or 

15 whether to present the GUI screen modification options to the 
user once again to receive more changes (step 924). For 
example, the TKET server may transmit a signal asking the 
user if he has more changes to make. Based upon the 
response, either step 912 is repeated or the inventive method 

20 of FIGURE 9 is complete. 

Each of the above steps for creating a GUI screen page 
may be performed multiple times to create multiple GUI screen 
pages. For example, a user realizing that he will want to 
access the GUI screen page from two different terminals, each 

25 having significantly different data handling capacity, may 
want to define a GUI screen page for each of the two 
terminals. Accordingly, when the user logs into the GUI 
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screen server, he is able to select the desired GUI screen 
page . 

FIGURE 10 is a flow chart illustrating a method for 
generating a GUI screen page to a user and for receiving data 
inputs from the user for storing and processing. Initially, 
when the user logs in, the TKET server examines the user ID 
so that it may determine the necessary information for 
generating a GUI screen page to the user (step 1004). 
Thereafter, the TKET server determines the group IDs and 
memberships that correspond to the user ID received from the 
user (step 1008) . 

As a part of determining how to set up a GUI screen 
page, the invention includes determining what type of 
communication channel is to be used to transmit the created 
GUI screen page (step 1012). For example, this step includes 
determining whether the GUI screen page is to be transmitted 
via wireless data link, through a low bandwidth serial line 
by way of a modem such as a typical 56K byte/sec desktop 
computer modem, or through high speed serial digital 
communication link utilizing a Tl or T3 line. More 
generally, this step includes determining the data throughput 
capacity of the data link for slowest known data link between 
the user terminal and the TKET server. 

Knowing the data throughput capacity by determining the 
type of communication channel is important for determining 
what features to include in the page for transmission to the 
user. One part of determining data throughput capacity of 
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the data link is determining what the appropriate protocol 
for generating and transmitting the page should be. For 
example, hypertext markup language (HTML) is appropriate for 
a full GUI screen page being transmitted to a desktop 
terminal. Similarly, hand held device markup language (HDML) 
is appropriate for PDAs and other hand held devices while 
wireless application protocol (WAP) is appropriate of 
wireless devices or terminals. 

Finally, in order to determine the characteristics of 
the . GUI screen page that is to be created, the TKET 
determines the terminal type (step 1016) . For example, if 
the terminal type is a PDA, its capacity for receiving GUI 
screen displays having color information will likely be 
notably lower than the capacity of a desktop computer. 
Similarly, if the PDA is to receive the GUI screen page over 
a wireless link, then the amount of information that may be 
transmitted must- be reduced even further. Accordingly, a 
simpler GUI screen page should be created. 

In addition to the above steps of analyzing the system 
parameters that affect how much information may be used to 
form a GUI screen page for transmission to the terminal, the 
inventive method includes determining what user profiles have 
been previously defined for the user. Thus, the invention 
includes obtaining the user profiles that, in the preferred 
embodiment, are stored in a database and may be accessed by 
the user ID (step 1020) . Additionally, besides determining 
what the defined objects are for the user and how they should 
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be arranged on a GUI screen page, the data content of the 
objects must be retrieved so that the GUI screen page may be 
populated with the user's data (step 1024). 

At this point, the TKET server has determined the 
necessary information for building the GUI screen page. 
Thus, the next steps include building the GUI screen page 
(step 1028), transmitting it to the user (step 1032), 
receiving data entries from the user for some of the various 
objects of the GUI screen page (step 1036), and storing the 
data in a database (step 1040) . 

The above listed method steps for creating a GUI screen 
page according to network and user selected parameters may be 
practiced in one of several different manners. For example, 
in the described embodiment, the TKET server determines the 
type of GUI screen page that should be built for transmission 
to the user based upon transmission channel and terminal 
capacities. For this embodiment, the TKET server analyzes a 
user terminal ID to determine type of terminal. The user ID 
may be selected and entered by the user or it may be embedded 
in a set of setup signals transmitted by the terminal. 

With respect to the transmission channel, TKET server 
analyzes the source of the incoming communication link. By 
way of example, if the communication link is received by the 
TKET server from a mobile switching center of a wireless 
network, then the TKET server determines that a wireless 
communication link is included in the communication path. In 
the described embodiment, the TKET server maintains a list of 
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prefix numbers that identify the mobile switching centers. 
The list of numbers and their originating sources may be 
operated in a manner similar a telecommunication network 
service control point. 

In an alternate embodiment of the invention, the first 
time a user establishes a link to a TKET server for a 
session, the server merely sends a signal to the terminal to 
prompt it to generate an immediate response in order to 
measure a response time. By measuring the response time, the 
TKET server is able to roughly determine data transport 
capacity through the established communication link for that 
session. Accordingly, it is at least partially from this 
approximation that the TKET server selects the size and 
complexity of the GUI screen page that it builds for 
transmission to the user terminal. 

In yet another embodiment of the invention, the TKET 
server initially selects one of a plurality GUI screen 
formats according to terminal type. Thereafter, GUI screen 
elements are implied according to the communication channel 
performance. For example, if the select GUI screen that 
corresponds to terminal type includes color information, but 
the communication channel response time does not allow for 
color information to be transmitted without incurring a delay 
beyond a specified amount, the TKET server may create an 
implied GUI screen that does not include color information. 
Thus, as may be seen, the invention includes determining the 
complexity of the GUI screen that is to be built not only by 
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operator selection, but also by system capabilities or 
performance . 

The actual parameters that are to be selected or 
discarded for those embodiments in which a full set of GUI 
5 screen display signals is not to b e generated by the TKET 
server makes the determination may readily be modified 
according to implementation of the inventive methods herein. 
In general however, they include decisions about whether to 
transmit color information, whether to transmit graphical 

10 symbols, logos and designs or even font information, whether 
to transmit specified advertisements, and whether to transmit 
certain arrangement information. 

FIGURE 11 is a functional block diagram illustrating a 
TKET server in communication with a user terminal according 

15 to an alternate embodiment of the invention. Referring now 
to FIGURE 11, it may be seen that a TKET server 1100 is in 
communication with a user terminal having a display screen 
1104. As may be seen from viewing screen 1104, three URLs 
representing different display options from which the user 

20 may choose are being displayed. Each display option 
represents different display nodes. 

First, option 1108 labeled ''Full" is for enabling the 
user to select a full GUI screen display node. Option 1112 
is for enabling the user to select a reduced GUI screen 

25 display while .option 1116 is for allowing the user to select 
a minimum display. The user selection is then transmitted by 
the user terminal in a user selection signal 1120 that is 
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transmitted to TKET server 1100. A display module 1124 
within TKET server 1100 is operable to receive signal 1120 
and to generate display signals to create a GUI screen 
display responsive thereto. 
5 While the example of FIGURE 11 illustrates the user 

being given URLs to select GUI screen display signal 
characteristics being transmitted by the TKET server, other 
approaches may be employed. More specifically, the URLs are 
used to cause the communication link to establish a 

10 communication link to an internet address. The TKET server, 
utilizes generates GUI screen display signals having 
characteristics that correspond to the URL. Thus, for the 
example of FIGURE 11, because three URL addresses are shown, 
the TKET server has at least three different sets of URL 

15 signal display characteristics to generate responsive 
thereto. In an alternate embodiment of the invention, 
however, a GUI screen display may prompt the user to select 
from a plurality of display characteristics. The user choice 
is then transmitted to the TKET server for it to generate GUI 

20 screen display signals having characteristics that are 
responsive thereto . 

In one embodiment of the invention, each of the options 
presented to the user on screen 1104 is one that triggers a 
different URL which causes signal 1120 to be transmitted to 

25 different destinations. In another embodiment of the 

invention, each of the choices is merely identified and 
reflected within signal 1120. Accordingly, display module 
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1124 extracts the selected choice from signal 1120 and 
generates the display signals to create a GUI screen that is 
responsive thereto . 

FIGURE 12 is a table illustrating a method within a TKET 
server for generating a GUI screen display at a remote 
terminal according to one embodiment of the invention. In 
the described embodiment, the display module of TKET server 
102 analyzes the terminal type to select from one of at least 
four different display types. For example, as is shown in 
column 1204, desktop computers and laptop computers receive a 
set of display signals for generating a full GUI screen 
display. In other words, a fully defined GUI screen display 
is generated at the remote terminal responsive to a set of 
signals that cause such a display being received by the 
remote terminal and transmitted by the TKET server. Column 
1208, however, illustrates a reduced set of display signals 
that might be transmitted to what is being referred to herein 
as a mini laptop. A mini laptop, as defined herein, is a 
device that, in terms of data storage and processing 
capacity, is somewhere between a PDA such as a Palm Pilot® 
and a laptop computer. Many companies are now starting to 
produce very powerful PDA's that contain or communication 
transceivers capable of supporting reasonably high data 
throughput rates but that do not provide the power and speed 
of a modern laptop.- 

Column 1212 illustrates that for certain types of 
terminals, such as a PDA, a minimal set of display signals 
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are to be transmitted thereby resulting in the user terminal 
displaying a minimal GUI screen display. For example, if the 
user terminal is a wireless PDA, then a set of display 
signals that would generate a minimal GUI screen display are 
transmitted by the display module of the TKET server. 
Finally, if the terminal is merely a telephone having a very 
limited display capacity, as is shown in column 1216, the 
display signals may comprise little more than text and 
control signals for the text. Alternatively, if the user 
terminal is a telephonic device, the ^'display signals" may 
comprise nothing more than voice information generated by an 
IVR. Alternatively, the display signals for phones might be 
a combination of text and voice signals. 

For each of these types of devices, there are multiple 
ways that the display module and/or other modules within the 
TKET server 102, of FIGURE 1 for example, may determine the 
type of user terminal. The protocol being used by the 
terminal in establishing a communication link with the TKET 
server can be very revealing as to the type of terminal. 

For example, if TKET server 102 of FIGURE 1 analyzes a 
received signal to determine whether the remote user terminal 
is using an HTML, an HDML or a WAP protocol for 
communicating. If the terminal is using HTML, then it 
probably 'is a device having the capability of a desktop, a 
laptop or other similar computer. If the protocol is a WAP 
protocol, then the TKET server may determine that the 
communication path includes a wireless link. If the protocol 
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is an HTML protocol, the TKET server may determine that the 
backup user terminal is a PDA. 

FIGURE 13 is a table illustrating a method for 
determining whether to generate a set of signals for 
displaying either a full, reduced or minimal GUI screen 
display based upon communication path characteristics 
according to one aspect of the present invention. Referring 
now to the exemplary system described FIGURE 13, it is seen 
that one of at least three different display modes of full, 
reduced and minimal are illustrated in columns 1304, 1308 and 
1312, respectively. It should be understand the invention 
includes having different numbers of display nodes. 
Additionally, rows 1316, 1320 and 1324 illustrate different 
communication path characteristics that influence the display 
mode or type of GUI screen display screen that is generated 
by the TKET server. 

Examining row 1316, if the communication link is an 
integrated services digital network (ISDN), a Tl, a new 
generation wireless (for example, 3G) communication link or 
if the communication link is transceived by a modem having a 
modem bit rate that equals or exceeds 56K, then the TKET 
server generates a full GUI screen display. Alternatively, 
if the user terminal modem is slower than a 56K modem or a 
wireless communication link that is older than a 3G wireless 
communication link, then the TKET server generates a reduced 
GUI screen display. Alternatively, if the wireless 

communication link includes transmission from a satellite 
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system, the known latencies associated with satellite 
transmissions as well as the expense for a satellite link 
prompts the TKET server to transmit a minimal set of display 
signals that will prompt the receiving user terminal to 
generate a minimal GUI screen display. 

Referring now to row 1320, it may be seen that the 
number of gateways can also influence whether a full, reduced 
or minimal set of display signals are transmitted for the 
generation of the GUI screen display screen. In one 

embodiment of the present invention, if the display signals 
have a communication path that includes only a number of 
gateways that is less than a defined number "A", then a full 
GUI screen display is transmitted unless there is a different 
reason for reducing the magnitude of the GUI screen display 
screen. However, if the number of gateways is within a 
range, by way of example, between and including the numbers A 
and B, then a reduced set of signals are transmitted to 
create a reduced GUI screen display. Finally, if the number 
of gateways exceeds the number B, then a minimal set of 
display signals are transmitted to create a minimal GUI 
screen display. In one described embodiment, A is set equal 
to one and B is set equal to three. 

Row 1324 illustrates that geography may also be used to 
determine whether to transmit a full, reduced or minimal set 
of display signals to create corresponding GUI screen display 
screens. For example, if the display signals are being 
transmitted through the various networks to a geographic 
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location that is within the North American continent, then a 
full set of display signals is transmitted. If, on the other 
hand, the signals are being transmitted either to Central 
7\merica, South America or Europe, then a reduced set of 
display signals are transmitted to create a reduced GUI 
screen display screen. Finally, for all other locations, by 
way of example, the Far East, the Middle East or Australia or 
New Zealand, then a minimal set of display signals to create 
a minimal GUI screen display screen are transmitted. In 
summary, therefore, the table of FIGURE 13 illustrates that 
the type of communication networks, the number of gateways, 
and the geographic location of the receiver or user are all 
significant parameters in determining whether to transmit a 
full, reduced or minimal set of display signals to create the 
corresponding full, reduced or minimal GUI screen display 
screens in a preferred embodiment of the invention. It is 
understood, of course that these geographic restrictions are 
exemplary. Moreover, even if there are actual restrictions 
today, inappropriately in data transportation technology will 
lead to different geographic constraint parameters. 

FIGURE 14 is a flow chart that illustrates a method 
according to the present invention. Referring now to FIGURE 
14, the method may be explained in view of the various 
networks illustrated in FIGURE 1. For the present method, 
TKET server 102 is operable to receive calls that originate 
from landline phones, by way of example, phone 124 coupled to 
a telephone network 106, and calls that originate from a 
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wireless terminal, e.g. wireless terminal 120, , 121, or 122, 
in a wireless network 110. Each of these calls, in the 
described embodiment, are transmitted through a gateway 
device similar to gateway device 108 of FIGURE 1 where they 
are converted from an original form (e.g., analog, time 
division multiple access (TDMA) code division multiple access 
(CDMA) and put into an IP packet format to be transmitted 
through the internet 104 directly to TKET server 102. 

In the described example, TKET server 102 is coupled to 
communicate with an integrated voice response unit 138. 
Accordingly, when TKET server 102 receives data packets from 
internet 104 that originated from a phone, by way of example, 
telephone 124, or wireless terminal 120, TKET server 102 
prompts IVR 138 to play a request for an ID. IVR 138 either 
produces that voice request in a digitized form or analog 
form. If it is produced in an analog form, TKET server 102 
is operable to convert the analog signal to digital and to 
transmit it over the internet 104 through the corresponding 
gateway 108 or 112 to the telephone 124 or wireless terminal 
120. According to the type of system, the signal is 
eventually converted to an analog signal for playing through 
a phone speaker. Thus, the initial message generated by IVR 
138 is to prompt the user to state or enter his ID (step 
1402) . 

Thereafter, through the network and various conversions 
described above, TKET server 102 receives and stores the 
response (step 1404). The manner of receiving and storing 
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responses from IVRs is known. Thereafter, the TKET server 
prompts the IVR to play a message to prompt the user to 
select either start or stop (step 1406) . The response is 
then stored (step 1408) . Additionally, TKET server prompts 
5 the IVR to request an account code, which is then played and 
transmitted to the user (step 1410) . Again, the response is 
stored (step 1412) . 

As may be seen from examining the method of FIGURE 14, 
the invention includes a TKET server that is coupled to an 

10 IVR to prompt the IVR to play select messages. The select 
messages are then placed into a digital form, transmitted in 
data packets through the internet and then converted by a 
gateway into a format that is appropriate for the telephone 
network through which they are to be transmitted. 

15 Thereafter, the converted signals are transmitted through a 
telephone network to the destination user terminal telephone. 

In an alternate embodiment of the invention, many of the 
computer instructions that, upon execution, result in the 
method steps being performed, may also be implemented within 

20 a telecommunication switch. For this embodiment, the switch 
itself is coupled to the IVR to generate the messages. The 
computer instructions stored within the switch would then 
prompt the IVR to request an ID, request the user to select 
between start and stop, and to request the IVR to enter a 

25 message to request the user to enter an account code, and 
finally to store each of the responses as shown in steps 1404 
through 1412. An additional step, however, is that the 
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switch must generate and transmit a message to the TKET 
server containing the user ID, the start/stop selection, and 
the account code at a minimal so that the TKET server may 
start or stop tracking time as is appropriate. Thus, step 
1414 is indicated as optional depending on what device 
performs the inventive method. 

If the inventive method is performed by a 
telecommunication switch, then, in the preferred embodiment, 
the generated message is formed using an HTTP protocol and is 
transmitted over the internet. 

FIGURE 15 is a flow chart illustrating an inventive 
method for receiving time tracking signals from a 
telecommunication switch according to a preferred embodiment 
of the invention. Referring now to FIGURE 15, the method 
includes receiving the message (step 1502) . As described 
before, in the preferred embodiment of the invention, the 
message is received using an IP protocol. The TKET server 
then extracts the user ID (step 1504), extracts the account 
code (step 1506) , and extracts the start/stop status (step 
1508) . Thereafter, the TKET server stores the time entry 
event that is defined by the extracted signals from steps 
1504 through 1508 (step 1510) . Thus, in relation to an 
account code, the user ID is stored along with a start/stop 
status. The TKET server also determines the total amount of 
time that the user entered for the given account code. 

In addition to extracting the account code, start or 
stop status and the user ID, the TKET server evaluates 
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whether additional information is required. If additional 
information is required, then it generates a GUI screen 
display signal to request information according to terminal 
type (step 1512) . For example, if the terminal type is a 
telephone, then the display signals will comprise little more 
than text. If the terminal is a desktop or lap top computer, 
then the TKET server will generate a set of display signals 
to cause the user terminal to generate a full GUI screen to 
request additional information . 

FIGURE 14 is a functional block diagram illustrating the 
circuitry within a time keeping and expense entry server 
according to one embodiment of the present invention. As may 
be seen, a TKET server 1400 includes a processor 1404, a 
memory 1408, a temporary memory 1412, and a bus controller 
1416, each of which is connected to a bus 1420. Memory 1408 
is formed of a hard drive while temporary memory 1412 is 
formed of random access memory. In general, memory 1408 is 
for storing computer instructions that define the operational 
logic of the server 1400 as described herein this application 
with particular reference to the illustrated methods and 
processors , Thus , processor 14 04 receives the computer 
instructions by way of bus 1420 and executes them. The 
processor, as needed, temporarily stores data, by way of bus 
1420, within temporarily memory 1412. The processor may be 
any known type of processor. While the permanent memory in 
the described embodiment is a hard drive, any type of - memory 



Docket No. JOUR-004 



capable of retaining information through power cycles may be 
used . 

The entire server, as well as the modules described in 
this application is formed logically by the processor' s 
execution of the stored computer instructions. The server 
and/or modules may, in alternate embodiments, be implemented 
by application specific integrated circuits. 

As may also be seen, a network interface 142 4 is 
connected to the controller 1416 to enable the server 1400 to 
communicate with other external devices. 

FIGURE 16 is a functional block diagram illustrating the 
circuitry within a time keeping and expense entry server 
according to one embodiment of the present invention. As may 
be seen, a TKET server 1600 includes a processor 1604, a 
memory 1608, a temporary memory 1612, and a bus controller 
1616, each of which is connected to a bus 1620. Memory 1608 
is formed of a hard drive while temporary memory 1612 is 
formed of random access memory. In general, memory 1608 is 
for storing computer instructions that define the operational 
logic of the server 1600 as described, herein this application 
with particular reference to the illustrated methods and 
processors. Thus, processor 1604 receives the computer 
instructions by way of bus 1620 and executes them. The 
processor, as needed, temporarily stores data, by way of bus 
1620, within temporary memory 1612. The processor may be any 
known type of processor. While the permanent memory in the 
described embodiment is a hard drive, any type of memory 
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capable of retaining information through power cycles may be 
used. As may also be seen, a network interface 1624 is 
connected to the controller 1616 to enable the server 1600 to 
communicate with other external devices. 
5 The modules described in this application are formed 

logically by the processor's execution of the stored computer 
instructions. The server and/or modules may, in alternate 
embodiments, be implemented by application specific 
integrated circuits or other known circuit design approaches 

10 made to implement a specified logic design. 

The invention disclosed herein is susceptible to various 
modifications and alternative forms. Specific embodiments 
therefor have been shown by way of example in the drawings 
and detailed description. It should be understood, however, 

15 that the drawings and detailed description. It should be 
understood, however, that the drawings and detailed 
description thereto are not intended to limit the invention 
to the particular form disclosed, but on the contrary, the 
invention is to cover all modifications, equivalents and 

20 alternatives falling within the spirit and scope of the 
present invention as defined by the claims. 
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